As the abilities of computers expand into entertainment genres that once required separate electronic components, increased efficiency and user-friendliness is desirable. One solution is Microsoft's® DirectShow®, which provides playback of multimedia streams from local files or Internet servers, capture of multimedia streams from devices, and format conversion of multimedia streams. DirectShow enables playback of video and audio content of file types such as MPEG, Apple® QuickTime®, Audio-Video Interleaved (AVI), and WAV.
DirectShow is an open and componentized system. With such a system problems with buffering and stream alignment limit the degree of interactivity between an application and user-perceived changes in the actual playback speed. The actual playback speed determines the amount of time that each frame of data is displayed. Fast playback rates typically display frames for shorter periods of time than slower playback rates, unless a fast playrate displays only keyframes or I-frames, in which case the rate of a frame's position in the content may be such that they are displayed for a longer period of time. Full content fast playback rates have high bandwidth requirements that can exceed most processor storage retrieval and hardware capabilities. Usually fast playback rates are approximated using so-called “scan modes” that selectively present only a (small) portion of a data stream by discarding some of the data of the stream. This is somewhat analogous to a rapidly progressing slide show.
Many video applications, such as those that execute on computers or in connection with interactive television sets, are composed of a user interface that controls a source (or source filter). The source (or source filter) is part of a data processing pipeline that processes the data so that the data can be ultimately rendered for a user. The source reads media files and typically passes the data samples or buffers (which are usually compressed using, e.g., MPEG) to some type of decoder for processing. The decoder decompresses the data and passes it to some type of renderer for rendering the data. The renderer typically uses an internal (or external) clock, and various timing information that is included with the data samples themselves, to present or render the samples at the correct time. When the renderer begins processing, an initial rendering clock time can be passed to the source and decoder. The source can then begin to produce samples with timestamps that start at some point after the initial renderer time. The timestamps are used by the renderer to schedule and render the various data samples based on their authored time of presentation. Small delays between pipeline and/or processing components, can occur since samples are buffered between each stage in the data processing pipeline. Pipeline latency is the cumulative propagation delay of the sample from the source to the time that it is presented or rendered. A continuing goal of developers to enable systems to smoothly playback data, such as video content, at different playback rates, for both forward and reverse directions. The nature of data processing pipelines and various data formats, however, continues to present challenges to developers.